An embedded system is usually a software/hardware unit which is connected to a surrounding system or entire system via sensors and/or actuators and/or interfaces. For example, an embedded system can perform monitoring, open-loop control, or closed-loop control tasks.
In this context, an embedded system is understood to be not only the concrete hardware implementation of the embedded system, but also preliminary stages in the development of a hardware-implemented embedded system, that is, for example, a software model for simulating such an embedded system.
To achieve a high quality standard, it is common practice to test embedded systems, such as electronic control units, extensively before their introduction into production, and thereby to check whether they comply with the specified requirements. Thus, the requirements to be applied to an embedded system must be known for such tests, and also, but not only, for the development of such tests.
Requirements are usually specified by the customers of a manufacturer of such an embedded system and normally take the form of a natural-language requirement, for example, a text written by the person specifying the requirement.
The problem arises here that the natural language, whichever language it is, is not usually unambiguous, and the described requirements can therefore be unclear.
Further, such requirements, which may, for example, express a property or action of an embedded system, must be tested, for which it is common practice to write appropriate test programs, either to test the embedded systems after their hardware implementation or to test the earlier software model on which the embedded system is based.
Programmers then write software routines which are not in themselves understandable, particularly to an inexperienced observer, so that it is not possible, from looking at the software routines, to draw direct conclusions about what is tested by a software routine and what the result will express.